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Abstract 


The ability to compute shortest constrained Traffic Engineering Label 
Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and 
Generalized MPLS (GMPLS) networks across multiple domains has been 
identified as a key requirement. In this context, a domain is a 
collection of network elements within a common sphere of address 
management or path computational responsibility such as an IGP area 
or an Autonomous Systems. This document specifies a procedure 
relying on the use of multiple Path Computation Elements (PCEs) to 
compute such inter-domain shortest constrained paths across a 
predetermined sequence of domains, using a backward-recursive path 
computation technique. This technique preserves confidentiality 
across domains, which is sometimes required when domains are managed 
by different service providers. 
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1. Introduction 


The requirements for inter-area and inter-AS MPLS Traffic Engineering 
(TE) have been developed by the Traffic Engineering Working Group (TE 
WG) and have been stated in [RFC4105] and [RFCA4216], respectively. 


The framework for inter-domain Multiprotocol Label Switching (MPLS) 
Traffic Engineering (TE) has been provided in [RFC4726]. 


[RFC5152] defines a technique for establishing an inter-domain 
Generalized MPLS (GMPLS) TE Label Switched Path (LSP) whereby the 
path is computed during the signaling process on a per-domain basis 
by the entry boundary node of each domain (each node responsible for 
triggering the computation of a section of an inter-domain TE LSP 
path is always along the path of such TE LSP). This path computation 
technique fulfills some of the requirements stated in [RFC4105] and 
[RFC4216] but not all of them. In particular, it cannot guarantee to 
find an optimal (shortest) inter-domain constrained path. 
Furthermore, it cannot be efficiently used to compute a set of inter- 
domain diversely routed TE LSPs. 


The Path Computation Element (PCE) architecture is defined in 
[RFC4655]. The aim of this document is to describe a PCE-based path 
computation procedure to compute optimal inter-domain constrained 
(G)MPLS TE LSPs. 


Qualifying a path as optimal requires some clarification. Indeed, a 
globally optimal TE LSP placement usually refers to a set of TE LSPs 
whose placements optimize the network resources with regards to a 
Specified objective function (e.g., a placement that reduces the 
maximum or average network load while satisfying the TE LSP 
constraints). In this document, an optimal inter-domain constrained 
TE LSP is defined as the shortest path satisfying the set of required 
constraints that would be obtained in the absence of multiple domains 
(in other words, in a totally flat IGP network between the source and 
destination of the TE LSP). Note that this requires the use of 
consistent metric schemes in each domain (see Section 13). 
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1.1. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. Terminology 


ABR: Area Border Routers. Routers used to connect two IGP areas 
(areas in OSPF or levels in IS-IS). 


ASBR: Autonomous System Border Router. Router used to connect 
together ASes of the same or different service providers via one or 
more inter-AS links. 

Boundary Node (BN): a boundary node is either an ABR in the context 
of inter-area Traffic Engineering or an ASBR in the context of 


inter-AS Traffic Engineering. 


Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along 
a determined sequence of domains. 


Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along 
a determined sequence of domains. 


Inter-area TE LSP: A TE LSP that crosses an IGP area boundary. 
Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 

LSP: Label Switched Path. 

LSR: Label Switching Router. 


PCC: Path Computation Client. Any client application requesting a 
path computation to be performed by a Path Computation Element. 


PCE: Path Computation Element. An entity (component, application, or 
network node) that is capable of computing a network path or route 
based on a network graph and applying computational constraints. 
PCE(i) is a PCE with the scope of domain(i). 

TED: Traffic Engineering Database. 


VSPT: Virtual Shortest Path Tree. 


The notion of contiguous, stitched, and nested TE LSPs is defined in 
[RFC4726] and will not be repeated here. 
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General Assumptions 


In the rest of this document, we make the following set of 
assumptions common to inter-area and inter-AS MPLS TE: 


o Each IGP area or Autonomous System (AS) is assumed to be Traffic 
Engineering enabled. 


o No topology or resource information is distributed between domains 
(as mandated per [RFC4105] and [RFC4216]), which is critical to 
preserve IGP/BGP scalability and confidentiality. 


o While certain constraints like bandwidth can be used across 
different domains, other TE constraints (such as resource 
affinity, color, metric, etc. [RFC2702]) could be translated at 
domain boundaries. If required, it is assumed that, at the domain 
boundary nodes, there will exist some sort of local mapping based 
on policy agreement, in order to translate such constraints across 
domain boundaries during the inter-PCE communication process. 


o Each AS can be made of several IGP areas. The path computation 
procedure described in this document applies to the case of a 
single AS made of multiple IGP areas, multiple ASes made of a 
single IGP area, or any combination of the above. For the sake of 
simplicity, each AS will be considered to be made of a single area 
in this document. The case of an inter-AS TE LSP spanning 
multiple ASes, where some of those ASes are themselves made of 
multiple IGP areas, can be easily derived from this case by 
applying the BRPC procedure described in this document, 
recursively. 


o The domain path (the set of domains traversed to reach the 
destination domain) is either administratively predetermined or 
discovered by some means that is outside of the scope of this 
document. 


BRPC Procedure 


The BRPC procedure is a multiple-PCE path computation technique as 
described in [RFC4655]. A possible model consists of hosting the PCE 
function on boundary nodes (e.g., ABR or ASBR), but this is not 
mandated by the BRPC procedure. 


The BRPC procedure relies on communication between cooperating PCEs. 
In particular, the PCC sends a PCReq to a PCE in its domain. The 
request is forwarded between PCEs, domain-by-domain, until the PCE 
responsible for the domain containing the LSP destination is reached. 
The PCE in the destination domain creates a tree of potential paths 
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to the destination (the Virtual Shortest Path Tree - VSPT) and passes 
this back to the previous PCE in a PCRep. Each PCE in turn adds to 
the VSPT and passes it back until the PCE in the source domain uses 
the VSPT to select an end-to-end path that the PCE sends to the PCC. 


The BRPC procedure does not make any assumption with regards to the 
nature of the inter-domain TE LSP that could be contiguous, nested, 
or stitched. 


Furthermore, no assumption is made on the actual path computation 
algorithm in use by a PCE (e.g., it can be any variant of Constrained 
Shortest Path First (CSPF) or an algorithm based on linear 
programming to solve multi-constraint optimization problems). 


4.1. Domain Path Selection 


The PCE-based BRPC procedure applies to the computation of an optimal 
constrained inter-domain TE LSP. The sequence of domains to be 
traversed is either administratively predetermined or discovered by 
some means that is outside of the scope of this document. The PCC 
MAY indicate the sequence of domains to be traversed using the 
Include Route Object (IRO) defined in [RFC5440] so that it is 
available to all PCEs. Note also that a sequence of PCEs MAY be 
enforced by policy on the PCC, and this constraint can be carried in 
the PCEP path computation request (as defined in [PCE-MONITOR]). 


The BRPC procedure guarantees to compute the optimal path across a 
specific sequence of traversed domains (which constitutes an 
additional constraint). In the case of an arbitrary set of meshed 
domains, the BRPC procedure can be used to compute the optimal path 
across each domain set in order to get the optimal constrained path 
between the source and the destination of the TE LSP. The BRPC 
procedure can also be used across a subset of all domain sequences, 
and the best path among these sequences can then be selected. 


4.2. Mode of Operation 
Definition of VSPT(i) 
In each domain i: 


o There is a set of X-en(i) entry BNs noted BN-en(k,i) where 
BN-en(k,i) is the kth entry BN of domain(i). 


o There is a set of X-ex(i) exit BNs noted BN-ex(k,i) where 
BN-ex(k,i) is the kth exit BN of domain(i). 


Vasseur, et al. Standards Track [Page 6] 


RFC 5441 BRPC April 2009 


VSPT (i): MP2P (multipoint-to-point) tree returned by PCE(i) to 
PCE(i-1): 


Root (TE LSP destination) 


/ | N 
BN-en(1,i) BN-en(2,i) ... BN-en(j,i). 
where [X-en(i)] is the number of 


entry BNs in domain i and j<= [X-en(i)] 
Figure 1: MP2P Tree 


Each link of tree VSPT(i) represents the shortest constrained path 
between BN-en(j,i) and the TE LSP destination that satisfies the set 
of required constraints for the TE LSP (bandwidth, affinities, etc.). 
These are path segments to reach the TE LSP destination from 
BN-en(j,i). 


Note that PCE(i) only considers the entry BNs of domain(i), i.e., 


only the BNs that provide connectivity from domain(i-1). In other 
words, the set BN-en(k,i) is only made of those BNs that provide 
connectivity from domain (i-1) to domain(i). Furthermore, some BNs 


may be excluded according to policy constraints (either due to local 
policy or policies signaled in the path computation request). 


Step 1: 

First, the PCC needs to determine the PCE capable of serving its path 
computation request (this can be done with local configuration or via 
IGP discovery (see [RFC5088] and [RFC5089])). The path computation 
request is then relayed until reaching a PCE(n) such that the TE LSP 
destination resides in the domain(n). At each step of the process, 
the next PCE can either be statically configured or dynamically 
discovered via IGP/BGP extensions. If no next PCE can be found or 
the next-hop PCE of choice is unavailable, the procedure stops and a 
path computation error is returned (see Section 9). If PCE(i-1) 
discovers multiple PCEs for the adjacent domain(i), PCE(i) may select 
a subset of these PCEs based on some local policies or heuristics. 
The PCE selection process is outside of the scope of this document. 


Step 2: 

PCE(n) computes VSPT(n), the tree made of the list of shortest 
constrained paths between every BN-en(j,n) and the TE LSP destination 
using a suitable path computation algorithm (e.g., CSPF) and returns 
the computed VSPT(n) to PCE(n-1). 
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Step i: 

For i-n-1 to 2: PCE(i) computes VSPT(i), the tree made of the 
shortest constrained paths between each BN-en(j,i) and the TE LSP 
destination. It does this by considering its own TED and the 
information in VSPT(i-1). 


In the case of inter-AS TE LSP computation, this also requires adding 
the inter-AS TE links that connect the domain(i) to the domain (i+1). 


Step n: 

Finally, PCE(1) computes the end-to-end shortest constrained path 
from the source to the destination and returns the corresponding path 
to the requesting PCC in the form of a PCRep message as defined in 
[RFC5440]. 


Each branch of the VSPT tree (path) may be returned in the form of an 
explicit path (in which case, all the hops along the path segment are 
listed) or a loose path (in which case, only the BN is specified) so 
as to preserve confidentiality along with the respective cost. In 
the latter case, various techniques can be used in order to retrieve 
the computed explicit paths on a per-domain basis during the 
Signaling process, thanks to the use of path keys as described in 
[PATH-KEY]. 


A PCE that can compute the requested path for more than one 
consecutive domain on the path SHOULD perform this computation for 
all such domains before passing the PCRep to the previous PCE in the 
sequence. 


BRPC guarantees to find the optimal (shortest) constrained inter- 
domain TE LSP according to a set of defined domains to be traversed. 
Note that other variants of the BRPC procedure relying on the same 
principles are also possible. 


Note also that in case of Equal Cost Multi-Path (ECMP) paths, more 
than one path could be returned to the requesting PCC. 


5.  PCEP Protocol Extensions 


The BRPC procedure requires the specification of a new flag of the RP 
object carried within the PCReq message (defined in [RFC5440]) to 
Specify that the shortest paths satisfying the constraints from the 
destination to the set of entry boundary nodes are requested (such a 
set of paths forms the downstream VSPT as specified in Section 4.2). 


Vasseur, et al. Standards Track [Page 8] 


RFC 5441 BRPC April 2009 


The following new flag of the RP object is defined: 
VSPT Flag 


Bit Number Name Flag 
25 VSPT 


When set, the VSPT Flag indicates that the PCC requests the 
computation of an inter-domain TE LSP using the BRPC procedure 
defined in this document. 


Because path segments computed by a downstream PCE in the context of 
the BRPC procedure MUST be provided along with their respective path 
costs, the C flag of the METRIC object carried within the PCReq 
message MUST be set. It is the choice of the requester to 
appropriately set the O bit of the RP object. 


6. VSPT Encoding 


The VSPT is returned within a PCRep message. The encoding consists 
of a non-ordered list of Explicit Route Objects (EROs) where each ERO 
represents a path segment from a BN to the destination specified in 
the END-POINT object of the corresponding PCReq message. 


Example: 

Kasco area 1l —---»«---- area: 0) -—---- > area 2 —-2--- > 
ABR1-A-B-+ 
ABR2----- D 
ABR3--C---* 


Figure 2: An Example of VSPT Encoding Using a Set of EROS 


In the simple example shown in Figure 2, if we make the assumption 
that a constrained path exists between each ABR and the destination 
D, the VSPT computed by a PCE serving area 2 consists of the 
following non-ordered set of EROs: 


o ERO1: ABR1 (TE Router ID)-A(Interface IP address)-B(Interface IP 
address)-D(TE Router ID 


— 


o ERO2: ABR2(TE Router ID)-D(TE Router ID) 


o ERO3: ABR3(TE Router ID)-C(interface IP address)-D(TE Router ID) 


The PCReq message, PCRep message, PCEP END-POINT object, and ERO 
object are defined in [RFC5440]. 
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7. 


Inter-AS TE Links 


In the case of inter-AS TE LSP path computation, the BRPC procedure 
requires the knowledge of the traffic engineering attributes of the 
inter-AS TE links. The process by which the PCE acquires this 
information is out of the scope of the BRPC procedure, which is 
compliant with the PCE architecture defined in [RFC4655]. 


That said, a straightforward solution consists of allowing the ASBRs 
to flood the TE information related to the inter-ASBR links although 
no IGP TE is enabled over those links (there is no IGP adjacency over 
the inter-ASBR links). This allows the PCE of a domain to get entire 
TE visibility up to the set of entry ASBRs in the downstream domain 
(see the IGP extensions defined in [RFC5316] and [RFC5392]). 


Usage in Conjunction with Per-Domain Path Computation 


The BRPC procedure may be used to compute path segments in 
conjunction with other path computation techniques (such as the per- 
domain path computation technique defined in [RFC5152]) to compute 
the end-to-end path. In this case, end-to-end path optimality can no 
longer be guaranteed. 


BRPC Procedure Completion Failure 


If the BRPC procedure cannot be completed because a PCE along the 
domain does not recognize the procedure (VSPT flag of the RP object), 
as stated in [RFC5440], the PCE sends a PCErr message to the upstream 
PCE with an Error-Type-4 (Not supported object), Error-value-4 


(Unsupported parameter). The PCE may include the parent object (RP 
object) up to and including (but no further than) the unknown or 
unsupported parameter. In this case where the unknown or unsupported 


parameter is a bit flag (VSPT flag), the included RP object should 
contain the whole bit flag field with all bits after the parameter at 
issue set to zero. The corresponding path computation request is 
then cancelled by the PCE without further notification. 


If the BRPC procedure cannot be completed because a PCE along the 
domain path recognizes but does not support the procedure, it MUST 
return a PCErr message to the upstream PCE with an Error-Type "BRPC 
procedure completion failure". 


The PCErr message MUST be relayed to the requesting PCC. 


PCEP-ERROR objects are used to report a PCEP protocol error and are 
characterized by an Error-Type that specifies the type of error and 
an Error-value that provides additional information about the error 
type. Both the Error-Type and the Error-value are managed by IANA. 
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A new Error-Type is defined that relates to the BRPC procedure. 


Error-Type Meaning 
13 BRPC procedure completion failure 
Error-value 
1: BRPC procedure not supported by one or more PCEs 
along the domain path 


Applicability 


As discussed in Section 3, the requirements for inter-area and 
inter-AS MPLS Traffic Engineering have been developed by the Traffic 
Engineering Working Group (TE WG) and have been stated in [RFC4105] 
and [RFC4216], respectively. Among the set of requirements, both 
documents indicate the need for some solution that provides the 
ability to compute an optimal (shortest) constrained inter-domain TE 
LSP and to compute a set of diverse inter-domain TE LSPs. 


1. Diverse End-to-End Path Computation 


PCEP (see [RFC5440]) allows a PCC to request the computation of a set 
of diverse TE LSPs by setting the SVEC object's flags L, N, or S to 
request link, node, or SRLG (Shared Risk Link Group) diversity, 
respectively. Such requests MUST be taken into account by each PCE 
along the path computation chain during the VSPT computation. In the 
context of the BRPC procedure, a set of diversely routed TE LSPs 
between two LSRs can be computed since the path segments of the VSPT 
are simultaneously computed by a given PCE. The BRPC procedure 
allows for the computation of diverse paths under various objective 
functions (such as minimizing the sum of the costs of the N diverse 
paths, etc.). 


By contrast, with a 2-step approach consisting of computing the first 
path followed by computing the second path after having removed the 
set of network elements traversed by the first path (if that does not 
violate confidentiality preservation), one cannot guarantee that a 
solution will be found even if such solution exists. Furthermore, 
even if a solution is found, it may not be the most optimal one with 
respect to an objective function such as minimizing the sum of the 
paths’ costs, bounding the path delays of both paths, and so on. 
Finally, it must be noted that such a 2-step path computation 
approach is usually less efficient in terms of signaling delays since 
it requires that two serialized TE LSPs be set up. 
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.2. Path Optimality 


BRPC guarantees that the optimal (shortest) constrained inter-domain 
path will always be found, subject to policy constraints. Both in 
the case where local path computation techniques are used (such as to 
build stitched or nested TE LSPs), and in the case where a domain has 
more than one BN-en or more than one BN-ex, it is only possible to 
guarantee optimality after some network change within the domain by 
completely re-executing the BRPC procedure. 


Reoptimization of an Inter-Domain TE LSP 


The ability to reoptimize an existing inter-domain TE LSP path has 
been explicitly listed as a requirement in [RFC4105] and [RFC4216]. 
In the case of a TE LSP reoptimization request, the reoptimization 
procedure defined in [RFC5440] applies when the path in use (if 
available on the head-end) is provided as part of the path 
computation request so that the PCEs involved in the reoptimization 
request can avoid double bandwidth accounting. 


Path Computation Failure 


If a PCE requires to relay a path computation request according to 
the BRPC procedure defined in this document to a downstream PCE and 
no such PCE is available, the PCE MUST send a negative path 
computation reply to the requester using a PCReq message as specified 
in [RFC5440] that contains a NO-PATH object. In such case, the 
NO-PATH object MUST carry a NO-PATH-VECTOR TLV (defined in [RFC5440]) 
with the newly defined bit named "BRPC path computation chain 
unavailable" set. 


Bit number Name Flag 
28 BRPC path computation chain unavailable 


Metric Normalization 


In the case of inter-area TE, the same IGP/TE metric scheme is 
usually adopted for all the IGP areas (e.g., based on the link-speed, 
propagation delay, or some other combination of link attributes). 
Hence, the proposed set of mechanisms always computes the shortest 
path across multiple areas that obey the required set of constraints 
with respect to a specified objective function. Conversely, in the 
case of inter-AS TE, in order for this path computation to be 
meaningful, metric normalization between ASes may be required. One 
Solution to avoid IGP metric modification would be for the service 
providers to agree on a TE metric normalization scheme and use the TE 
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metric for TE LSP path computation (in that case, the use of the TE 
metric must be requested in the PCEP path computation request) using 
the METRIC object (defined in [RFC5440]). 


14. Manageability Considerations 
This section follows the guidance of [PCE-MANAGE]. 
14.1. Control of Function and Policy 


The only configurable item is the support of the BRPC procedure on a 
PCE. The support of the BRPC procedure by the PCE MAY be controlled 
by a policy module governing the conditions under which a PCE should 
participate in the BRPC procedure (origin of the requests, number of 
requests per second, etc.). If the BRPC is not supported/allowed on 
a PCE, it MUST send a PCErr message as specified in Section 9. 


14.2. Information and Data Models 
A BRPC MIB module will be specified in a separate document. 
14.3.  Liveness Detection and Monitoring 


The BRPC procedure is a multiple-PCE path computation technique and, 
as such, a set of PCEs are involved in the path computation chain. 

If the path computation chain is not operational either because at 
least one PCE does not support the BRPC procedure or because one of 
the PCEs that must be involved in the path computation chain is not 
available, procedures are defined to report such failures in Sections 
9 and 12, respectively. Furthermore, a built-in diagnostic tool to 
check the availability and performances of a PCE chain is defined in 
[PCE-MONITOR]. 


14.4.  Verifying Correct Operation 
Verifying the correct operation of BRPC can be performed by 
monitoring a set of parameters. A BRPC implementation SHOULD provide 


the following parameters: 


o Number of successful BRPC procedure completions on a per-PCE-peer 
basis 


o Number of BRPC procedure completion failures because the VSPT flag 
was not recognized (on a per-PCE-peer basis) 


o Number of BRPC procedure completion failures because the BRPC 
procedure was not supported (on a per-PCE-peer basis) 
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14.5. Requirements on Other Protocols and Functional Components 


The BRPC procedure does not put any new requirements on other 
protocols. That said, since the BRPC procedure relies on the PCEP 
protocol, there is a dependency between BRPC and PCEP; consequently, 
the BRPC procedure inherently makes use of the management functions 
developed for PCEP. 


14.6. Impact on Network Operation 


The BRPC procedure does not have any significant impact on network 
operation: indeed, BRPC is a multiple-PCE path computation scheme as 
defined in [RFC4655] and does not differ from any other path 
computation request. 


14.7. Path Computation Chain Monitoring 


[PCE-MONITOR] specifies a set of mechanisms that can be used to 
gather PCE state metrics. Because BRPC is a multiple-PCE path 
computation technique, such mechanisms could be advantageously used 
in the context of the BRPC procedure to check the liveness of the 
path computation chain, locate a faulty component, monitor the 
overall performance, and so on. 


15. IANA Considerations 

15.1. New Flag of the RP Object 
A new flag of the RP object (specified in [RFC5440]) is defined in 
this document. IANA maintains a registry of RP object flags in the 
"RP Object Flag Field" sub-registry of the "Path Computation Element 
Protocol (PCEP) Numbers" registry. 


IANA has allocated the following value: 


Bit Description Reference 
25 VSPT This document 
15.2. New Error-Type and Error-Value 


IANA maintains a registry of Error-Types and Error-values for use in 
PCEP messages. This is maintained as the "PCEP-ERROR Object Error 
Types and Values" sub-registry of the "Path Computation Element 
Protocol (PCEP) Numbers" registry. 
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A new Error-value is defined for the Error-Type "Not supported 
object" (type 4). 


Error-Type Meaning and error values Reference 
4 Not supported object 
Error-value-4: Unsupported parameter This document 


A new Error-Type is defined in this document as follows: 


Error-Type Meaning Reference 
13 BRPC procedure completion failure This document 
Error-value-1: BRPC procedure not This document 


supported by one or more PCEs along 
the domain path 


15.3. New Flag of the NO-PATH-VECTOR TLV 


A new flag of the NO-PATH-VECTOR TLV defined in [RFC5440]) is 
Specified in this document. 


IANA maintains a registry of flags for the NO-PATH-VECTOR TLV in the 
"NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation 
Element Protocol (PCEP) Numbers" registry. 


IANA has allocated the following allocation value: 


Bit number Meaning Reference 
4 BRPC path computation This document 
chain unavailable 


16. Security Considerations 


The BRPC procedure relies on the use of the PCEP protocol and as such 
is subjected to the potential attacks listed in Section 10 of 
[RFC5440]. In addition to the security mechanisms described in 
[RFC5440] with regards to spoofing, snooping, falsification, and 
denial of service, an implementation MAY support a policy module 
governing the conditions under which a PCE should participate in the 
BRPC procedure. 


The BRPC procedure does not increase the information exchanged 


between ASes and preserves topology confidentiality, in compliance 
with [RFC4105] and [RFC4216]. 
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